home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc906.txt < prev    next >
Text File  |  1994-08-01  |  10KB  |  228 lines
  1.  
  2. Network Working Group                                     Ross Finlayson
  3. Request for Comments: 906                            Stanford University
  4.                                                                June 1984
  5.  
  6.                       Bootstrap Loading using TFTP
  7.  
  8.  
  9. Status of this Memo
  10.  
  11.    It is often convenient to be able to bootstrap a computer system from
  12.    a communications network.  This RFC proposes the use of the IP TFTP
  13.    protocol for bootstrap loading in this case.
  14.  
  15.    This RFC specifies a proposed protocol for the ARPA Internet
  16.    community, and requests discussion and suggestions for improvements.
  17.  
  18. Introduction
  19.  
  20.    Many computer systems, such as diskless workstations, are
  21.    bootstrapped by loading one or more code files across a network.
  22.    Unfortunately, the protocol used to load these initial files has not
  23.    been standardized - numerous methods have been employed by different
  24.    computer manufacturers. This can make it difficult, for example, for
  25.    an installation to support several different kinds of systems on a
  26.    local-area network.  Each different booting mechanism that is used
  27.    must be supported, for example by implementing a number of servers on
  28.    one or more host machines.  This is in spite of the fact that these
  29.    heterogeneous systems may be able to communicate freely (all using
  30.    the same protocol) once they have been booted.
  31.  
  32.    We propose that TFTP (Trivial File Transfer Protocol) [6] be used as
  33.    a standard protocol for bootstrap loading.  This protocol is
  34.    well-suited for our purpose, being based on the standard Internet
  35.    Protocol (IP) [4].  It is easily implemented, both in the machines to
  36.    be booted, and in bootstrap servers elsewhere on the net.  (In
  37.    addition, many popular operating systems already support TFTP
  38.    servers.)  The fact that TFTP is a rather slow protocol is not a
  39.    serious concern, due to the fact that it need be used only for the
  40.    primary bootstrap.  A secondary bootstrap could use a faster
  41.    protocol.
  42.  
  43.    This RFC describes how system to be booted (called the "booter"
  44.    below) would use TFTP to load a desired code file.  It also describes
  45.    an existing implementation (in ROM) for Ethernet.
  46.  
  47.    Note that we are specifying only the network protocols that would be
  48.    used by the booting system.  We do not attempt to mandate the method
  49.    by which a user actually boots a system (such as the format of a
  50.    command typed at the console).  In addition, our proposal does not
  51.  
  52.  
  53.  
  54.  
  55. Finlayson                                                       [Page 1]
  56.  
  57.  
  58.  
  59. RFC 906                                                        June 1984
  60.  
  61.  
  62.    presuppose the use of any particular data-link level network
  63.    architecture (although the example that we describe below uses
  64.    Ethernet).
  65.  
  66. Network Protocols used by the Booting System
  67.  
  68.    To load a file, the booter sends a standard TFTP read request (RRQ)
  69.    packet, containing the name of the file to be loaded.  The file name
  70.    should not assume any operating system dependent naming conventions
  71.    (file names containing only alphanumeric characters should suffice).
  72.    Thereafter, the system receives TFTP DATA packets, and sends TFTP ACK
  73.    and/or ERROR packets, in accordance with the TFTP specification [6].
  74.  
  75.    TFTP is implemented using the User Datagram Protocol (UDP) [5], which
  76.    is in turn implemented using IP.  Thus, the booter must be able to
  77.    receive IP datagrams containing up to 524 octets (excluding the IP
  78.    header), since TFTP DATA packets can be up to 516 octets long, and
  79.    UDP headers are 8 octets long.  The booting machine is not required
  80.    to respond to incoming TFTP read or write requests.
  81.  
  82.    We allow for the use of two additional protocols.  These are ARP
  83.    (Address Resolution Protocol) [3], and RARP (Reverse Address
  84.    Resolution Protocol) [1]. The possible use of these protocols is
  85.    described below.  The booter could also use other protocols (such as
  86.    for name lookup), but they should be IP-based, and an internet
  87.    standard.
  88.  
  89.    The IP datagram containing the initial TFTP RRQ (and all other IP
  90.    datagrams sent by the booter) must of course contain both a source
  91.    internet address and a destination internet address in its IP header.
  92.    It is frequently the case, however, that the booter does not
  93.    initially know its own internet address, but only a lower-level (e.g.
  94.    Ethernet) address.  The Reverse Address Resolution Protocol
  95.    (RARP) [1] may be used by the booter to find its internet address
  96.    (prior to sending the TFTP RRQ).  RARP was motivated by Plummer's
  97.    Address Resolution Protocol (ARP) [3].  Unlike ARP, which is used to
  98.    find the 'hardware' address corresponding to a known higher-level
  99.    protocol (e.g. internet) address, RARP is used to determine a
  100.    higher-level protocol address, given a known hardware address.  RARP
  101.    uses the same packet format as ARP, and like ARP, can be used for a
  102.    wide variety of data-link protocols.
  103.  
  104.    ARP may also be used.  If the destination internet address is known,
  105.    then an ARP request containing this address may be broadcast, to find
  106.    a corresponding hardware address to which to send the subsequent TFTP
  107.    RRQ.  It may not matter if this request should fail, because the RRQ
  108.    can also be broadcast (at the data-link level).  However, because
  109.    such an ARP request packet also contains the sender's (that is, the
  110.  
  111.  
  112. Finlayson                                                       [Page 2]
  113.  
  114.  
  115.  
  116. RFC 906                                                        June 1984
  117.  
  118.  
  119.    booter's) internet and hardware addresses, this information is made
  120.    available to the rest of the local subnet, and could be useful for
  121.    routing, for instance.
  122.  
  123.    If a single destination internet address is not known, then a special
  124.    'broadcast' internet address could be used as the destination address
  125.    in the TFTP RRQ, so that it will be received by all 'local' internet
  126.    hosts.  (At this time, however, no standard for internet broadcasting
  127.    has been officially adopted. [**])
  128.  
  129. An Example Implementation
  130.  
  131.    The author has implemented TFTP booting as specified above.  The
  132.    resulting code resides in ROM.  (This implementation is for a
  133.    Motorola 68000 based workstation, booting over an Ethernet.)  A user
  134.    wishing to boot such a machine types a file name, and (optionally)
  135.    the internet address of the workstation, and/or the internet address
  136.    of a server machine from which the file is to be loaded.  The
  137.    bootstrap code proceeds as follows:
  138.  
  139.       (1) The workstation's Ethernet address is found (by querying the
  140.       Ethernet interface).
  141.  
  142.       (2) If the internet address of the workstation was not given, then
  143.       a RARP request is broadcast, in order to find it.  If this request
  144.       fails (that is, times out), then the bootstrap fails.
  145.  
  146.       (3) If the internet address of a server host was given, then
  147.       broadcast an ARP request to try to find a corresponding Ethernet
  148.       address.  If this fails, or if a server internet address was not
  149.       given, then the Ethernet broadcast address is used.
  150.  
  151.       (4) If the internet address of a server host was not given, then
  152.       we use a special internet address that represents a broadcast on
  153.       the "local subnet", as described in [2].  (This is not an internet
  154.       standard.)
  155.  
  156.       (5) A TFTP RRQ for the requested file is sent to the Ethernet
  157.       address found in step (3).  The source internet address is that
  158.       found in step (2), and the destination internet address is that
  159.       found in step (4).
  160.  
  161.    Note that because several TFTP servers may, in general, reply to the
  162.    RRQ, we do not abort if a TFTP ERROR packet is received, because this
  163.    does not preclude the possibility of some other server replying later
  164.    with the first data packet of the requested file.  When the first
  165.    valid TFTP DATA packet is received in response to the RRQ, the source
  166.    internet and Ethernet addresses of this packet are used as the
  167.  
  168.  
  169. Finlayson                                                       [Page 3]
  170.  
  171.  
  172.  
  173. RFC 906                                                        June 1984
  174.  
  175.  
  176.    destination addresses in subsequent TFTP ACK packets.  Should another
  177.    server later respond with a DATA packet, an ERROR packet is sent back
  178.    in response.
  179.  
  180.    An implementation of TFTP booting can take up a lot of space if care
  181.    is not taken.  This can be a significant problem if the code is to
  182.    fit in a limited amount of ROM.  However, the implementation
  183.    described above consists of less than 4K bytes of code (not counting
  184.    the Ethernet device driver).
  185.  
  186. Acknowledgements
  187.  
  188.    The ideas presented here are the result of discussions with several
  189.    other people, in particular Jeff Mogul.
  190.  
  191. References
  192.  
  193.    [1]  Finlayson, R.,  Mann, T.,  Mogul, J.  & Theimer, M.,  "A Reverse
  194.         Address Resolution Protocol", RFC 903  Stanford University,
  195.         June 1984.
  196.  
  197.    [2]  Mogul, J., "Internet Broadcasting",  Proposed RFC, January 1984.
  198.  
  199.    [3]  Plummer, D., "An Ethernet Address Resolution Protocol",
  200.         RFC 826,  MIT-LCS, November 1982.
  201.  
  202.    [4]  Postel, J., ed., "Internet Protocol - DARPA Internet Program
  203.         Protocol Specification", RFC 791, USC/Information Sciences
  204.         Institute, September 1981.
  205.  
  206.    [5]  Postel, J., "User Datagram Protocol", RFC 768 USC/Information
  207.         Sciences Institute, August 1980.
  208.  
  209.    [6]  Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, MIT/LCS,
  210.         June 1981.
  211.  
  212.     
  213.    
  214.  
  215.  
  216.    [**]  Editor's Note:  While there is no standard for an Internet wide
  217.         broadcast or multicast address, it is strongly recommended that
  218.         the "all ones" local part of the Internet address be used to
  219.         indicate a broadcast in a particular network.  That is, in class
  220.         A network 1 the broadcast address would be 1.255.255.255, in
  221.         class B network 128.1 the broadcast address would be
  222.         128.1.255.255, and in class C network 192.1.1 the broadcast
  223.         address would be 192.1.1.255.
  224.  
  225.  
  226. Finlayson                                                       [Page 4]
  227.  
  228.